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(57) Abstract 

A multi-user electronic sign management system (10) incorporates an electronic communications link (34, 36, 38) to permit the receipt 
of message requests from a plurality of independent users. The message requests received over the electronic communications link (34, 
36, 38), which are associated with selected messages and selected times to display those messages, are processed by the sign management 
system (10) to generate control signals suitable for controlling the display of such messages on an electronic sign (12, 14, 16) at appropriate 
times. 
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MULTI-USER ELECTRONIC SIGN MANAGEMENT SYSTEM 

Field of the Invention 

5 The invention is generally related to electronic signs, and in particular to the 

generation, scheduling and display of messages on electronic signs. 

Background of the Invention 
Electronic signs are used in a multitude of applications to display 

10 informational and/or entertainment messages such as announcements or 

advertisements to persons viewing the signs. For example, electronic signs are often 
used in public facilities such as airports and train stations to display arrival and 
departure information to travelers, and are used on roads to provide traffic information 
to drivers. Other concerns such as hotels, malls, retail stores, supermarkets, theaters, 

15 convention centers, sports facilities, restaurants, bars, casinos, and the like, may also 
utilize electronic signs, e.g., to advertise upcoming events or specials, or to provide 
informational messages to customers and/or potential customers. 

Electronic signs are often located either indoors or outdoors, and typically in 
public places where large numbers of relevant viewers can view the signs. A number 

20 of different display technologies have been developed, including incandescent lights, 
light emitting diodes (LED's), liquid crystal displays (LCD's), cathode ray tubes 
(CRT's) and plasma displays (among others). Electronic signs can significantly vary 
in display capability. For example, electronic signs can be as simple as small 
monochrome 7-segment LED or LCD displays capable of displaying only a few 

25 digital characters at a time. Electronic signs can also be as complex as large full-color 
billboard-type displays capable of displaying animation and full-morion video, such 
as Sony JumboTron displays found in locations such as stadiums and arenas, as well 
as in Times Square in New York City. 
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An electronic sign is typically controlled by a sign controller implemented as a 
dedicated electronic controller or a general purpose computer running sign control 
software, and interfaced with the sign through a wired or wireless interface. Often, an 
operator is capable of creating/editing messages, schedule messages, and perform 
5 maintenance functions for a sign via a sign controller. Furthermore, in some 

applications, multiple signs may be controlled by a single device such as a server, and 
connected via a wired or wireless network. The signs may be owned by the same 
party, or may be owned by different parties and managed by a single entity contracted 
by the parties to manage their signs. 

10 Some electronic signs are used exclusively by their owners to display 

messages such as announcements and/or advertisements related solely to the owners' 
interests. Other electronic signs are used exclusively as a source of supplemental 
revenue to display messages for others for a fee. Still other electronic signs may be 
used to display both types of messages, enabling the signs' owners (also referred to as 

15 "message display service providers") to generate a profit or at least recoup some of 
the costs of the electronic signs through supplemental advertising revenue. 

Generating revenue from electronic signs, however, can be problematic due to 
the difficulties involved in matching potential advertisers with message display 
service providers « often quantified in terms of the "transactional costs" or overhead 

20 associated with contracting for the display of an advertisement on a particular 

electronic sign. For example, a potential advertiser in New York might wish to run an 
advertisement on an electronic sign in Las Vegas. However, the potential advertiser 
may not know where the best location to run the advertisement in Las Vegas would 
be, or if a particular location is identified, who is the owner of a sign at that location. 

25 Often, to handle placement of the advertisement, the advertiser would contact an 
advertising agency in New York, who would then attempt to locate and contact 
another agency in Las Vegas that works with one or more providers to assist in 
locating a desirable sign and handling the transaction. The Las Vegas agency, often 
with assistance from the New York agency, would typically produce the 

30 advertisement in the format required for the particular sign, and would handle the 
contractual, scheduling and monetary issues as required to ensure that the 
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advertisement is displayed as agreed and the message display service provider is 
compensated accordingly. 

The amount of interaction between agencies, advertisers, and message display 
service providers typically magnifies the transactional costs to an advertiser, 
5 specifically in terms of monetary expense, delay and overall effort and frustration. As 
such, in many instances electronic sign advertising may only be economically 
justified for only relatively large advertisement orders, e.g., to display one or more 
advertisements on multiple signs and/or multiple times on a given sign over a 
particular time period, where the percentage attributable to transactional costs is 

10 relatively low. For the smaller advertiser that wants to run an advertisement only a 
few times at a single location, the time and effort is often simply not justified. 

In addition, some message display service providers permit individuals to 
contract to have personal announcements such as birthdays, wedding proposals, 
anniversaries, and the like to be displayed on their signs. However, as with smaller 

15 advertisers, often the transactional costs limit the availability of such services to many 
individuals. 

It is believed that a significant amount of potential advertising revenue is lost 
due to the excessive transactional costs associated with conventional manners of 
contracting for the display of advertisements on electronic signs. It is similarly 

20 believed that lowering such costs would make electronic sign advertising a viable 
option for a greater number and variety of potential users, and in turn increase 
advertising revenues for message display service providers and the like. 

Therefore, a significant need exists in the art for a manner of facilitating the 
interaction between message display service providers and the potential users of such 

25 services, in particular for lowering the transactional costs, time and effort associated 
with securing the display of messages on electronic signs, and otherwise simplifying 
the procedure for programming electronic signs. 
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Summary of the Invention 

The invention addresses these and other problems associated with the prior art 
by providing an apparatus, program product, and method of controlling an electronic 
sign in which an electronic communications link in a sign management system is used 
5 to accept message requests from a plurality of users. The message requests received 
over the electronic communications link, which are associated with selected messages 
and selected times to display those messages, may then be processed by the sign 
management system to generate control signals suitable for controlling the display of 
such messages at the appropriate times. 

10 By accepting message requests over an electronic communications link, 

multiple independent users are often able to independently secure the display of 
desired messages on a given electronic sign with significantly lower transactional 
costs, as well as with reduced delays and processing times. For example, in one 
particularly useful application of the invention, a sign management system may be 

15 coupled to a public network such as the Internet to permit users that are completely 
independent of a message display service provider (as well as independent of one 
another) to request that specific messages be displayed on an electronic sign 
controlled by that provider. 

In addition to providing the ability to receive message requests over an 

20 electronic communications link, it may also be desirable to integrate additional 
features in a sign management system to further simplify the interaction between 
users and message display service providers. For example, in some applications it 
may be desirable to incorporate additional user information such as payment 
information with message requests, so that processing of the message requests can 

25 include the automated handling of payments between users and message display 
service providers. 

Moreover, in some applications it may be desirable to permit users to locate 
specific electronic signs out of a set of available signs that meet location, availability, 
display capability and/or other criteria suitable for the users' particular needs, and 
30 then direct message requests as appropriate to ensure that requested messages are 
displayed on selected electronic signs. 
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In some applications it may also be desirable to provide interactive message 
generation capabilities that permit users to construct messages that are consistent with 
the display capabilities of the electronic signs upon which the messages are displayed. 
To further the ability of a user to construct a message, it may also be desirable to 
5 simulate the operation of an electronic sign in displaying that user's message so the 
user can get a better feel for the ultimate look and feel of the message. 

In other applications it may also be desirable to incorporate an image capture 
device, positioned to view an electronic sign, into a sign management system. 
Incorporation of an image capture device could permit, for example, a user to view a 
10 real-time image of an electronic sign during the process of selecting among multiple 
available signs. Also, a user could be provided with proof that a message was in fact 
displayed on an electronic sign by providing a captured image of the electronic sign 
during display of the message. 

These and other advantages and features, which characterize the invention, are 
15 set forth in the claims annexed hereto and forming a further part hereof. However, for 
a better understanding of the invention, and of the advantages and objectives attained 
through its use, reference should be made to the Drawings, and to the accompanying 
descriptive matter, in which there is described exemplary embodiments of the 
invention. 



20 
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Brief Description of the Drawings 

FIGURE 1 is a block diagram of a sign management system consistent with 
the invention. 

FIGURE 2 is a block diagram of a hardware platform for a server computer 
5 from the sign management system of Fig. 1 . 

FIGURE 3 is a block diagram illustrating the primary software components in 
a server computer and a user computer in the sign management system of Fig. 1. 

FIGURE 4 is a block diagram of a computer display from a user computer in 
the sign management system of Fig. 1, illustrating the display of a message request 
1 0 home page in a browser window. 

FIGURE 5 is a flowchart illustrating the sequence of operations performed in 
the sign management system of Fig. 1 during selection of a sign. 

FIGURE 6 is a block diagram illustrating a HTML document utilized during 
the sequence of operations of Fig. 5. 
15 FIGURE 7 is a flowchart illustrating the sequence of operations performed in 

the sign management system of Fig. 1 during creation or editing of a message. 

FIGURE 8 is a flowchart illustrating the program flow of a message editor 
application executed by a user computer in the sign management system of Fig. 1. 

FIGURE 9 is a block diagram illustrating a message editor window utilized by 
20 the message editor application of Fig. 8. 

FIGURE 10 is a block diagram of a message record data structure suitable for 
use in the sign management system of Fig. 1 . 

FIGURE 1 1 is a block diagram of a sign record data structure suitable for use 
in the sign management system of Fig. 1. 
25 FIGURE 12 is a block diagram of an order record data structure suitable for 

use in the sign management system of Fig. 1 . 

FIGURE 13 A is a flowchart illustrating the program flow of the convert 
message routine referenced in Fig. 8. 

FIGURE 13B is a flowchart illustrating the program flow of the create 
30 simulation routine referenced in Fig. 8. 

FIGURE 14 is a flowchart illustrating the sequence of operations performed in 
the sign management system of Fig. 1 during scheduling of a message. 
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FIGURES 15A and 15B are block diagram illustrating HTML documents 
utilized during the sequence of operations of Fig. 14. 

FIGURE 16 is a flowchart illustrating the sequence of operations performed in 
the sign management system of Fig. 1 during selection of a proof mode. 
5 FIGURE 17 is a block diagram illustrating a HTML document utilized during 

the sequence of operations of Fig. 16. 

FIGURE 18 is a flowchart illustrating the sequence of operations performed in 
the sign management system of Fig. 1 during selection of payment. 

FIGURES 19 A, 19B and 19C are block diagrams illustrating HTML 
10 documents utilized during the sequence of operations of Fig. 18. 

FIGURE 20 is a flowchart illustrating the sequence of operations performed in 
the sign management system of Fig. 1 during handling of a submitted order. 

FIGURE 21 is a flowchart illustrating the sequence of operations performed 
by the order verification module in the sign manager of Fig. 3. 
15 FIGURE 22 is a flowchart illustrating the sequence of operations performed 

by the monitoring & approval module in the sign manager of Fig. 3. 

FIGURE 23 is a flowchart illustrating the sequence of operations performed 
by the scheduler module in the sign manager of Fig. 3. 

FIGURE 24 is a flowchart illustrating the sequence of operations performed 
20 by the proof of display module in the sign manager of Fig. 3. 

FIGURE 25 is a block diagram of an alternate, distributed sign management 
system consistent with the invention. 

FIGURE 26 is a flowchart illustrating the sequence of operations performed to 
handle a message request in the sign management system of Fig. 25. 



25 
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Detailed Description 

Turning to the Drawings, wherein like numbers denote like parts throughout 
the several views, Fig. 1 illustrates a sign management system 10 consistent with the 
invention. Sign management system 10 is principally used to electronically interface 
5 one or more electronic signs (e.g., electronic signs 12, 14 and 16, owned and/or 

operated by one or more message display service providers) with a plurality of users, 
e.g., coupled to sign management system 10 through one or more user computers 18, 
20, 22. 

Each electronic sign 12, 14, 16 typically includes a dedicated sign controller 
10 24, 26, 28 that is configured to operate the electronic sign in any of several manners 
known in the art. Each controller 24-28 may be, for example, an embedded controller 
designed specifically for its associated electronic sign, or a general purpose computer 
executing software that is specifically tailored for the associated electronic sign. 
Various electronic communications links may be used to interface an electronic sign 
15 to its dedicated controller, including wired or wireless links, dial-up links, network 
links, etc. 

In general, each electronic sign may be considered to include practically any 
information display device, other than a requesting user's computer, that is capable of 
being viewed by the intended audience of a particular message. Each electronic sign 

20 may be implemented using any number of known display technologies, including 

LED's, LCD's, plasma displays, CRT's, banks or arrays of CRT's, bulb displays, flip 
dot displays, electro-mechanical displays, etc. Further, each electronic sign may be 
located outdoors or indoors — typically at any location well suited for viewing by the 
intended audience of the sign, e.g., in a public place. 

25 In the embodiment described hereinafter, sign management system 10 is 

principally implemented using one or more server computers (e.g., server computers 
30, 32) interfaced via electronic communications links between user computers 18-22 
and electronic signs 12-16. In other embodiments, however, other types of computers 
(e.g., personal computers, workstations, portable computers, minicomputers, 

30 midrange computers, mainframe computers, etc.), electronic devices (e.g., dedicated 
and/or embedded controllers), or combinations thereof may be used in the alternative 
to implement the sign management functions described herein. 
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The electronic communications link between each server computer and each 
user computer can be a public link, e.g., over a public communications network such 
as the Internet 34 (as with user computers 1 8 and 20), or over a private or proprietary 
link, e.g., direct or dial-up link 38 between server computer 32 and user computer 22. 
5 Similarly, the electronic communications link between each server computer and each 
electronic sign can be a public link (as illustrated by sign controller 28), or a private or 
proprietary link, e.g., links 36 between server computer 30 and sign controllers 24 and 
26. Furthermore, the electronic communications links between server computers in 
distributed applications where more than one server computer is utilized may also be 

10 public (as with server computers 30, 32) or private (not shown in Fig. 1). In addition, 
each electronic communications link between server computers 30,32 sign controllers 
24-28 and user computers 18-22 may be physically implemented using any known 
wired or wireless communications mediums, including but not limited to direct 
cables, radio frequency (RF) transmissions, analog or digital dial-up lines (e.g., 

15 POTS, ISDN, xDSL, or broadband cable), infrared (IR) transmissions, satellite 
transmissions, computer network cables, etc., and combinations thereof. 

As is also shown in Fig. 1, one or more image capture devices 40, 42 may also 
optionally be interfaced with sign management system 10, with each coupled to a 
server computer through either a private link (e.g., via direct cable 44 for image 

20 capture device 40) or a public link (e.g., as with image capture device 42). Each 
image capture device, which may be implemented, for example, using any 
commercially-available digital or analog still or video camera, is typically positioned 
relative to an associated electronic sign such that the display of messages on the 
electronic sign can be viewed through the image capture device. An image capture 

25 device may be located at a fixed location, with a fixed focus and field of display, or 
can have a varying field of display controllable by the server computer. Moreover, an 
image capture device may be integrated with additional communication electronics, 
e.g., to provide the electronic interface with a server computer, to compress captured 
images prior to transmission to a server computer, to handle commands from the 

30 server computer, etc. Moreover, one or more of such functions could be integrated 
into a server computer or a sign controller, among other variations. The use and 
operation of the image capture devices will be discussed in greater detail below. 



WO 00/63771 



PCTAJS00/10260 



-10- 

From a business perspective, the various components in a sign management 
system 10, as well as electronic signs 12-16, user computers 18-20, and the electronic 
communications links therebetween, may be owned and/or operated by the same or 
different entities. For example, an owner of one or more electronic signs may utilize a 
5 sign management system to rent advertising space on the signs from users having 
access to the system over the Internet or another public manner of access. Also, a 
sign management system could be owned and operated by an intermediary party that 
contracts with one or more owners of electronic signs to rent advertising space on 
those signs to independent users. The owner of a sign management system could also 

10 incorporate kiosks placed in public places such as retail malls and stores as user 

computers to permit users that would not otherwise have computer access to the sign 
management system to rent advertising space on an electronic sign. It will be 
appreciated that a wide variety of alternate business models are also possible 
consistent with the invention. 

15 As will become more apparent below, a principal advantage of the sign 

management system implementations disclosed herein is that the processes of 
creating, editing and/or retrieving message requests from users; processing those 
message requests to verify compatibility with sign capabilities; securing payment 
from users; monitoring message requests for appropriate content; scheduling message 

20 requests; controlling electronic signs to display those message requests; and providing 
feedback to users to confirm display of messages, may all or in part be implemented 
in a highly automated manner, requiring little if any human interaction beyond that of 
the users generating the message requests. As a consequence, the transactional costs 
typically associated with contracting for the display of messages on electronic signs 

25 are typically reduced, resulting in less effort, expense and frustration than 

conventional systems. Moreover, with reduced transactional costs, often individual 
users or small advertisers, who would not otherwise be willing to expend the time, 
effort and expense necessary to get a message displayed on an electronic sign, are 
more likely to rent advertising space, presenting additional advertising revenue 

30 opportunities for message display service providers. 

Fig. 2 illustrates an exemplary hardware and software environment for server 
computer 30. Computer 30 typically includes at least one processor 32 coupled to a 



WO 00/63771 



PCTrtJSOO/10260 



- 11- 

memory 34. Processor 32 may represent only one or multiple processors (e.g., 
microprocessors), and memory 34 may be implemented using any of a number of 
known memory architectures, including one or more levels of volatile memory such 
as dynamic random access memory (DRAM) and/or one or more levels of cache 
5 memory (whether integrated into or external to a processor), as well as various non- 
volatile or backup memories (e.g., programmable or flash memories), read-only 
memories, etc. In addition, memory 34 may be considered to include memory storage 
physically located elsewhere in or accessible by server computer 30, e.g., as stored in 
a mass storage device 38 or on another computer coupled to server computer 30 

1 0 through network interface 40. 

Server computer 30 also typically receives a number of inputs and outputs for 
communicating information externally. For interface with a user or operator, server 
computer 30 typically includes a terminal interface 36. Also, as discussed above, 
additional storage may be provided through the use of one or more mass storage 

15 devices 38, e.g., a floppy or other removable disk drive, a hard disk drive, a direct 
access storage device (DASD), an optical drive (e.g., a CD drive, a DVD drive, etc.), 
and/or a tape drive, among others. Furthermore, server computer 30 may include an 
one or more network interfaces 40 to interface the computer with one or more 
networked devices, e.g., other server computers, user computers, sign controllers, and 

20 the like, using any of the aforementioned communications links. It should be 

appreciated that server computer 30 typically includes suitable analog and/or digital 
interfaces between processor 32 and each of components 34, 36, 38 and 40 as is well 
known in the art. 

Each user computer likewise includes any of a number of conventional 
25 hardware environments, typically including one or more processors, a memory 
architecture, and various input/output devices as is well known in the art. A user 
computer can include any electronic device suitable for receiving user input and 
interacting with a user, as well as communicating with the sign management system. 
Exemplary devices can include, desktop or portable computers, hand-held computers, 
30 and kiosk terminals, among others. 

Server computer 30 operates under the control of an operating system 42, and 
executes or otherwise relies upon various computer software applications, 
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components, programs, objects, modules, data structures, etc. to implement the sign 
management functions described herein (e.g., sign manager 44 and user interface 46, 
among others). Moreover, various applications, components, programs, objects, 
modules, etc. may also execute on one or more processors in another computer 
5 coupled to computer 30 via a network, e.g., in a distributed or client-server computing 
environment, whereby the processing required to implement the functions of a 
computer program may be allocated to multiple computers over a network. 

In general, the routines executed to implement the embodiments of the 
invention, whether implemented as part of an operating system or a specific 

10 application, component, program, object, module or sequence of instructions will be 
referred to herein as "computer programs'*, or simply "programs". The computer 
programs typically comprise one or more instructions that are resident at various 
times in various memory and storage devices in a computer, and that, when read and 
executed by one or more processors in a computer, cause that computer to perform the 

15 steps necessary to execute steps or elements embodying the various aspects of the 

invention. Moreover, while the invention has and hereinafter will be described in the 
context of fully functioning computers and computer systems, those skilled in the art 
will appreciate that the various embodiments of the invention are capable of being 
distributed as a program product in a variety of forms, and that the invention applies 

20 equally regardless of the particular type of signal bearing media used to actually carry 
out the distribution. Examples of signal bearing media include but are not limited to 
recordable type media such as volatile and non-volatile memory devices, floppy and 
other removable disks, hard disk drives, optical disks (e.g., CD-ROM's, DVD's, etc.), 
among others, and transmission type media such as digital and analog communication 

25 links. 

In addition, various programs described hereinafter may be identified based 
upon the application for which they are implemented in a specific embodiment of the 
invention. However, it should be appreciated that any particular program 
nomenclature that follows is used merely for convenience, and thus the invention 
30 should not be limited to use solely in any specific application identified and/or 
implied by such nomenclature. 
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Those skilled in the art will recognize that the exemplary environments 
illustrated in Figs. 1 and 2 are not intended to limit the present invention. Indeed, 
those skilled in the art will recognize that other alternative hardware and/or software 
environments may be used without departing from the scope of the invention. 
5 Figure 3 illustrates the primary software components in a representative server 

computer 30 and user computer 1 8 in performing the various sign management 
functions described herein. The interaction between a user and the sign management 
system is principally implemented at the server end in user interface module 46, 
which in this implementation utilizes a transmission control protocol (TCP) server 50 

10 and a common gateway interface-binaries (CGI-BIN) gateway application 52. TCP 
server and gateway 52 may be implemented, for example, in any commercially- 
available Internet or **web" server application, as is well known in the art. From the 
user's perspective, the user interface functions are handled by a JAVA or Active X 
client application 54 and a web browser 56, each resident in the memory of user 

15 computer 18. 

CGI-BIN gateway 52 typically interacts with web browser 56 to provide a 
series of platform-independent forms, e.g., in the format of hypertext markup 
language (HTML) documents, for viewing on web browser 56. For user interface 
operations that cannot be handled using an HTML-based interface, however, a 

20 locally-resident client sign editor application 54 is typically utilized to supplement the 
user interface operations of the sign management system. 

In the illustrated implementation, for example, CGI-BIN gateway 52 and web 
browser 56 are utilized to handle sign management functions such as selecting 
electronic signs and selecting time slots for display of messages, as well as additional 

25 functions such as handling payment and other transactional issues, and providing an 
on-line tutorial for the user. Further functions, such as the display of disclaimers, 
retrieving images as proof of display or as a mementos, user authentication, 
confirmation of orders, and other features described below are generally allocated to 
the HTML-based components of the user interface. 

30 The client application 54 that executes locally on a user's computer interfaces 

with TCP server 50 to handle additional user interface operations that are not well 
suited for an HTML-based interface. Predominant among these operations is the 
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creation and editing of messages, as well as the simulation of those messages for 
display on a user's computer. As will be discussed in greater detail below, the client 
application may either be platform-independent, as with a JAVA applet, or may be a 
platform-dependent application, such as one or more Active X controls that are 
5 specific to the Microsoft Windows environment. Moreover, multiple client 
application formats may be supported to permit users having different platform 
capabilities and configurations to interface with the sign management system. Often, 
information about a particular user's capabilities and/or platform configuration (e.g., 
the user's operating system and platform) can be readily obtained (e.g., through the 

10 use of simple JavaScript functions and the like), so that automated determination of an 
optimal application format may be made. In the alternative, a user may be required to 
manually specify which of multiple application formats is optimal for the user. 

Further in the illustrated implementation, it is desirable to have TCP server 50 
download client application 54 to the user's computer during the initial interaction 

15 between the user and the sign management system. This eliminates the need for the 
user to specifically obtain and install the client application prior to interacting with the 
sign management system. 

It should be appreciated that a wide variety of alternate user interface 
applications may be utilized consistent with the invention, e.g., alternate interface 

20 protocols, including active server pages (ASP), scripting languages, and other 

platform-independent or specific applications that are either fully resident on the user 
computer or are downloaded on an as-needed basis from the server computer to the 
user computer. Moreover, in some implementations, much of the functionality can be 
allocated to the server computer, with the user computer acting more as a terminal that 

25 displays the results of the operations performed by the server computer. It should also 
be appreciated that the functionality of client application 54 and web browser 56 may 
be combined into a dedicated application, or that a web-type interface can be replaced 
with a proprietary interface, if desired. Furthermore, it may be desirable to support 
multiple platforms and configurations, or in the alternative, to require users to access 

30 the system through a single uniform interface. 

While a wide variety of other modifications may be made to the illustrated 
user interface, it should be appreciated that the implementation described herein relies 
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principally on the well-known and widely-available set of interface tools that are 
conventionally supported by a vast majority of the computers having access to the 
Internet and other public networks. As a result, a new user wishing to interact with a 
sign management system will typically have little difficulty in (1) directing 
5 commands and receiving instructions from the sign management system and (2) 
learning and understanding the interface provided by that system. As a result, the 
learning curve associated with interacting with the sign management system can be 
considerably reduced. 

Sign manager 44 principally implements the handling and processing of 

10 message requests generated via user interface 46. Sign manager 44 is under the 

principal control of a main control module 48, which is coupled to both TCP server 50 
and gateway 52, as well as to a database 58, an order verification module 60, a 
monitoring and approval module 62, a scheduler module 64 and a proof of display 
module 68. The primary functions performed by main control module 48 include 

15 receiving user requests from the user interface, retrieving information from database 
58, and calling and passing information between the various additional modules 60, 
62, 64 and 68 as necessary. 

Database 58 principally stores electronic records of the various message 
requests generated by users. Additional information may also be stored in database 

20 58, e.g., the display capabilities and other operating parameters of the various 

electronic signs controlled by the computer, user profile information, pre-existing 
message content and gallery information, and other required data. Order verification 
module 60 is principally responsible for verifying the eligibility of a user message 
request in terms of user profile, user payment and the overall compatibility of the 

25 request with various order parameters. Monitoring and approval module 62 is 

principally responsible for verifying that the message content is acceptable, e.g., not 
including any dirty words or other content unsuitable for a particular sign purpose. 
As will be discussed in greater detail below, monitoring and approval module 62 may 
include a content filter that is purely automated, and/or may include an additional 

30 manual component that requires human approval of the message request prior to 
display of that request on an electronic sign. 
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Scheduler module 64 is principally responsible for allocating time slots for 
message requests and transmitting control signals to the signs for display of the 
messages at the proper time. This module is also responsible for responding to 
requests from other components in the sign management system, e.g., so that a user 
5 can reserve a time slot and/or find out at what times a particular sign is available. As 
will also become more apparent below, scheduler module 64 may handle the actual 
scheduling of messages, or in the alternative, may transmit those messages prior to 
display to appropriate sign controllers having their own scheduling capabilities 
embedded therein. 

10 Scheduler module 64 is specifically interfaced with various sign controllers 

via sign control drivers 66. As with any other peripheral component in a computer 
system, each sign control driver 66 is configured to interact with scheduler module 64 
via a generic protocol, and to likewise interact with a particular sign controller based 
upon whatever specific requirements exist for that controller. As such, the scheduler 

1 5 module can be constructed to work with any type of sign, with only the program code 
in a particular sign controller driver specifically coded to conform to the particular 
requirements of the sign controller. 

Proof of display module 68 is principally responsible for interfacing the sign 
manager with any image capture devices controlled by the server computer. The 

20 proof of display module 68 may also include compression capabilities as well as 

synchronization capabilities to permit an image capture device to capture an image at 
a specific instant in time while a particular portion of a message is being display on its 
associated sign. Additional networking capabilities may be incorporated into server 
computer 30 to provide the electrical interface with the image capture devices as well 

25 as the various sign controllers to which the server computer is coupled. 

It should be appreciated that the various functions allocated to each of the 
modules in the sign management system can vary in different applications. Therefore, 
the invention should not be limited to the particular allocation of functions between 
the modules as shown in Fig. 3. 

30 Figs. 4-24 next describe the operation of the illustrated sign management 

system in generally the same order in which a user would interact with the system to 
generate and schedule a message request to be displayed on an electronic sign. These 
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different steps along the process are illustrated as being performed using any number 
of user interface mechanisms, including HTML pages, CGI scripts, and the operation 
of program code executing on either of the server or user computers. The 
implementation of these operations to effect the herein described user interface is well 
5 within the abilities of one of ordinary skill in the art having the benefit of the instant 
disclosure. Moreover, it will be appreciated that the different functional operations 
performed during the operation of the sign management system may be allocated to 
different components, handled by alternate user interface protocols, and handled in 
other manners consistent with the invention. 

10 Figure 4 illustrates, for example, a computer display 80 upon which is 

displayed a window 82 for a browser resident on a user's computer. Shown displayed 
within the browser window is a message request home page 84 that represents the 
initial user interface mechanism through which a user might generate a message 
request for sign management system 10. It is anticipated that a user could navigate 

15 directly to home page 84, or in the alternative, could be required to login, or 

authenticate, from a sign management home page prior to being granted access to the 
message request home page. User authentication typically requires that a user provide 
a user name and password to permit profile information about the user to be retrieved 
and utilized during the generation of the user request. As such, an additional service 

20 provided by the sign management system, but which is not shown separately herein, is 
that of authenticating new users. Such an operation would likely also entail the input 
of profile information about the user, such as name and address, e-mail address, credit 
card number, etc. 

Message request home page 84 includes a plurality of user interface controls 
25 86-99 through which a user can interactively construct a message request (also 

referred to herein as a "electronic order"). Each user interface control 86-99 is shown 
as a button control through which a user can select the control to navigate to another 
HTML document to operate on a specific portion of a message request. User interface 
control 86 is used to access a sign selection interface through which a user selects one 
30 or more of a plurality of available electronic signs to which a message request should 
be directed. User interface control 88 permits a user to interactively create and edit a 
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message to display on a selected electronic sign. User interface control 90 enables a 

user to schedule display of the selected message on the selected sign. 

User interface control 92 permits a user to select the mode in which the user 

will receive confirmation or proof of display of the selected message on the electronic 
5 sign. User interface control 94 permits a user to select a method of payment for the 

message request, and user interface control 96 initiates processing of the message 

request or order once all of the necessary information has been entered by the user. 
Additional controls may also be provided on home page 84. For example, it 

may be desirable to permit a user to access a disclaimer through user interface control 
10 98. The disclaimer may include, for example, information warning the user that the 

message display service provider is not liable for the content of any messages, and 

that liability rests solely on the user, similar to a newspaper advertising disclaimer. 

The disclaimer may also include warnings such as notifying the user of the inherent 

risks associated with electronic commerce. 
15 The user may also be able to access an on-line help tutorial through user 

interface control 99. The use of supplemental help systems to provide interactive 

assistance to a user is well known in the art, and thus will not be described in further 

detail herein. 

It should be appreciated that other mechanisms for accessing and constructing 
20 a message request may be used in the alternative. Therefore, the particular HTML- 
based mechanism described herein is merely exemplary, and should not be used to 
limit the invention. 

Figure 5 illustrates a flow chart 100 of the operations performed when 
selecting a sign upon selection of user interface control 86 of Fig. 4. First, in block 
25 102, sign parameters representing a search criteria are retrieved from a user. Next, in 
block 104, a list of signs matching the sign parameters input by the user are retrieved 
and displayed to the user. Next, in block 106, the sign management system waits for 
user input, and the sequence of blocks 108-1 14 detect and handle various types of user 
input received from a user. Block 108, for example, determines whether the user has 
30 requested a preview of a selected sign. If so, a digital image of the sign is retrieved in 
block 1 14. As shown in Fig. 5, the digital image may be a real-time image captured 
using an image capture device associated with that sign, the process of which is 



WO 00/63771 PCT/USOO/10260 

-19- 

described in greater detail below. In the alternative, a snapshot of an electronic sign, 
stored persistently in the sign management system, may be displayed in the 
alternative. 

Returning to block 108, if the received user input is not to preview a sign, 
5 block 1 1 0 next determines whether the user input is to select a sign for display of a 
desired message. If so, the sequence of operations is complete, typically resulting in 
the user being returned to message request home page 84 of Fig. 4. Block 112 
represents other user input that may be received from a user, but which is not relevant 
to the selection of a sign as described herein. 
10 Figure 6 illustrates, for example, one suitable HTML document 1 16 to be used 

during the sign selection process in connection with Fig. 5. Document 1 1 6 is 
implemented as a framed document, including a search frame 118 and a results frame 
120. 

Search frame 118 includes a plurality of user interface controls 122-130 

15 through which various sign parameters can be input by a user. Once the desired 
parameters are set, a button user interface control 132 may be selected by a user to 
initiate a search to retrieve and display a list of signs 134 in results frame 120. A 
selected sign is illustrated at 136, and a plurality of button controls 138-142 are shown 
for providing user input to the browser with respect to the currently selected sign. 

20 Specifically, button control 138 enables a user to accept the currently selected sign 
and return to the message request home page. Button control 140 performs a 
CANCEL operation, returning to the message request home page without selecting (or 
modifying a past selection) of a sign. Button control 142 accesses the preview 
function discussed above by opening an additional window 144 within which is 

25 displayed an image 146 of the selected electronic sign. 

A number of sign parameters may be input by a user to search and locate 
desirable electronic signs among those available through the sign management 
system. For example, controls 122 and 124 respectively permit a user to input width 
and height limitations on a sign so that only signs meeting a desired set of dimensions 

30 are retrieved. Controls 126, 128 and 130 respectively permit a user to input state, city 
and street location to locate a sign in a predetermined geographical location. Other 
sign parameters may also be utilized to restrict a search. For example, the scheduler 
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could be accessed to only return signs that are available for a desired time slot. 
Additional sign parameters may specify certain display capabilities of a sign, e.g., 
whether a sign is capable of displaying video, whether the sign is capable of colors, 
the display resolution or color depth of the sign, etc. It should also be appreciated that 
5 not all available sign parameters need be specified to limit the search results, and 
further, that other search criteria may be utilized to retrieve a subset of available 
electronic signs. 

Figure 7 next illustrates a flow chart 150 showing the sequence of operations 
performed during creation or editing of a message in response to selection of user 

10 interface control 88 of Fig. 4. Specifically, in response to a user request to create or 
edit a message through the HTML message request home page, a message editor 
client application is executed locally on a user's computer to handle the interactive 
editing function in creating a message. 

In the illustrated implementation, both JAVA and Active X versions of a 

15 message editor are supported such that, for Microsoft Windows-compatible user 

computers, Active X controls are utilized, while for other computing platforms where 
Active X controls are not supported, a platform-independent JAVA applet is 
downloaded to the user computer to perform similar functions. As a result, the first 
step in executing the message editor application is to determine in block 152 whether 

20 Active X is supported by the user's computer. This can be performed through 
requesting input from the user, or in the alternative, through the use of known 
JavaScript function calls. 

If Active X is not supported, a JAVA applet version of the message editor 
application is downloaded to the user computer in block 154. Next, in block 156, the 

25 JAVA applet is started on the user's computer, whereby the initialization of the sign 
editing process is commenced. 

Returning to block 152, if Active X is supported, it is next determined in block 
158 whether Active X controls are already resident in the user's computer — that is, if 
the Active X controls have already been downloaded to the user's computer in the 

30 past. If not, the Active X control version of the message editor is downloaded to the 
user computer in block 160. Next, the Active X controls are started on the user 
computer in block 162 to initiate the sign editing function. Returning to block 158, if 



WO 00/63771 PCT/USOO/10260 

-21- 

the Active X controls are already resident in the user computer, a download of the 
controls is not necessary, so the already-resident Active X controls can simply be 
started to initiate the sign editing process. 

Figure 8 illustrates the program flow of a message editor application 170 
5 consistent with the invention. Message editor application 1 70 generally operates 
using an event-driven programming model, whereby, after initializing the editing 
window in block 172, events are waited upon at block 174 and handled via one of 
blocks 176-196 as they are received. 

The initialization step performed in block 172 may also include retrieval of a 
10 message record if such a record already exists for the pending message request being 
constructed by a user. If, however, no message record has been constructed, the 
initialization step may also include initialization of a new message record in certain 
instances. 

One event that can be handled by message editor application 170 is that of 

15 creating a new page or message record, which is detected at block 1 76 and handled in 
block 198 by adding a new message record and initializing the editing window to 
display a fresh, unedited window. Addition of a message record may also include the 
association of the new message record with the old message record, e.g., by 
incorporating a pointer to the new message record in the old record. Once a new 

20 message has been added, control returns to block 174 to process additional events. 

Another event capable of being detected by message editor application 170 is 
an event to input text into the message, which is detected in block 178 and handled in 
block 200 by adding the input text to the message record. Control then passes to 
block 202 to update the message record to reflect the additional text. Moreover, block 

25 202 may also update the editing window to provide a what-you-see-is-what-you-get 
(WYSIWYG) or interactive editing operation. Control then returns to block 174 to 
process additional events. 

It may also be desirable to be able to import graphics and/or animation into a 
message, e.g., as stored locally on the user computer, or in the alternative, stored on a 

30 server computer or on another computer coupled to the user's computer (e.g., over the 
Internet). A request to import graphics is detected in block 1 80 and handled in block 
204 by retrieving a graphics file from the user. Control then returns to block 202 to 
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update the message record. A similar event for importing animation is detected in 
block 182 and handled in block 206 by retrieving an animation file from the user and 
updating the message record in block 202. Retrieval of a graphics or animation file is 
typically performed in an interactive manner, whereby a user is permitted to browse 
5 through a directory structure including appropriate graphics and animation files. A 
preview function may also be provided in a manner known in the art. 

Additional editing functions may be supported. For example, it may be 
desirable to modify the font and/or colors of textual information. Such a class of 
events may be detected in block 184 and handled in block 208 by retrieving new font 

10 and/or color selections from a user, and then updating the message record in block 
202. Moreover, it may be desirable to provide the ability to incorporate special 
effects into a message. Selection of such effects is detected in block 186 and handled 
in block 210 by presenting the user with a list of special effects. In addition, it may be 
desirable to provide the user with a preview of a selected effect. Within such a 

15 structure, a user selects an effect, which is detected in block 212, and control passes to 
block 202 to update the message record to reflect the new effect. 

Any number of known special effects may be incorporated into a message 
consistent with the invention, e.g., scroll effects, wipe effects, swipe effects, reveal 
effects, blink effects, inversion or flash effects, dissolve effects, rainbow effects, and 

20 others. 

Another event that may be handled by message editor 170 is a request to select 
another sign type. Such an event is detected in block 188 and handled in block 214 by 
getting new sign parameters from the user, e.g., in the same manner as described 
above with regard to searching for a desired sign. When new sign parameters are 

25 obtained, a convert message routine 216 is executed to modify the message as 

necessary to be compatible with the new sign parameters associated with the newly- 
selected sign type. Control then returns to block 202 to update the message record 
and wait for new events. 

It may also be desirable to support pre-existing message content via a message 

30 gallery stored on the server computer. A request to view such a message gallery is 
detected in block 190 and handled in block 218 by retrieving a message from the 
gallery in response to user input. Pre-existing messages may be stored, for example, 
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in a content portion of database 58, and may include text information, as well as 
video, animation, graphics, or other predefined messages that a user is able to use as is 
or to modify to generate a custom message therefrom. 

Yet another editing function supported by message editor 170 is a simulate 
5 function, which is detected in block 192 and handled in block 220 by creating a 
computer simulation of how a message defined by the current message record 
information would appear on the selected electronic sign. Creation of the simulation 
incorporates not only the contents of the message record, but also the display 
capabilities of the sign. Through the feedback provided by a simulation, a user is 

10 better able to anticipate how a message being edited will ultimately appear on the 
electronic sign when displayed. The modeling of a physical electronic sign based 
upon sign parameters such as display resolution, color depth, and other display 
capabilities would be well within the abilities of one of ordinary skill in the art having 
the benefit of the instant disclosure. The simulation modeling is an approximation of 

15 the physical sign display and it shows the message text and graphics, with limitations 
due to the capabilities of a standard computer display. 

Upon completion of the simulation, control returns to block 202, whereby the 
message record is updated if necessary, and the message editor waits for additional 
events. 

20 An additional event detected by message editor 170 is a DONE event, which is 

detected in block 194 and is used to signify the termination of the message editing 
process. As shown in block 196, additional edit events may also be supported by the 
message editor. These events, which are not relevant to the instant disclosure, would 
be apparent to one of ordinary skill in the art, and thus are not discussed in greater 

25 detail herein. 

Figure 9 illustrates, for example, an exemplary window 230 through which 
user interaction with message editor 170 may be handled. As shown in this figure, an 
editing region 232 is provided that simulates the look and feel of a particular sign 
(with, for example, the individual LED or LCD pixel locations delimited at 234 for 

30 the benefit of the user). An editing cursor 236 is also illustrated in the editing region. 
Furthermore, a menu bar 238 is shown providing access to advanced functions in the 
editor. Frequently used functions, such as the aforementioned new page, graphics and 



WO 00/63771 



PCT/US00/10260 



-24- 

animation import, font/color selection, effects selection, sign-type selection, gallery 
viewing and simulation functions, may be accessed through a series of toolbar button 
user interface controls 240. 

In general, a wide range of known editing and effect functions may be utilized 
5 to generate a message consistent with the invention. Specifically, it is anticipated that 
any of the known functionality incorporated into commercially-available word 
processors, desktop publishing applications, web publishing applications, presentation 
applications and the like may be utilized to construct a message consistent with the 
invention. As the functionality of these commercially-available applications is well 

10 understood by those of skill in the art, a further discussion of these specific features 
herein is not necessary for a full understanding of the invention. 

One suitable data structure for a message record is illustrated at 250 in Fig. 10. 
A message record may include, for example, a sequence of fields 252-264 providing 
various information about a message. Field 252 provides a record of the text to be 

15 displayed in the message. Field 254 identifies one or more graphic, video and/or 

animation files to be displayed in the message. Field 254 may also be used to provide 
a background for a text message, and multiple graphics images may be utilized and 
stored in this field to create animation. 

Field 256 provides sizing information representing the overall size of the 

20 message. Field 258 identifies the sign type for which the message is designed. Field 
260 identifies one or more special effects to be utilized in the message, and fields 262 
and 264 respectively provide speed indicators to indicate the speed at which an effect 
or an animation should be displayed (e.g., in frames per second). 

The text in a particular message record is represented by a list of line records 

25 266 pointed to by field 252. Each line record includes a string field 268 identifying a 
list of characters. A justification field 270 indicates whether left, center, right or full 
justification should be used for the list of characters. Fields 272 and 274 identify the 
length of the string and the coordinate of the line's left upper corner in the message. 
Field 276 includes a pointer to next line record 266 in the list of lines for the text 

30 message. 

Each line record identifies a linked list of character records 278 pointed to by 
string field 268. Each character record in turn includes a character code field 280 
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storing an ASCII code or special character to display. Fields 282, 284 and 286 
respectively identify a color, font size and font set for the character identified in field 
280. Field 288 provides a pointer to the next character record 278 in the list of 
characters for the line. 
5 It should be appreciated that additional and/or alternate information may be 

provided in each message record consistent with the invention. Moreover, alternate 
data structures may be utilized to represent the same information as provided in 
message record 250. 

Figure 1 1 illustrates a representative data structure for a sign record 288 that 

10 identifies various display capabilities and other sign parameters for a given sign. 
Field 290 provides a name or other identifier that uniquely identifies a given sign. 
Field 292 provides location information for the sign, including various geographical 
information such as state, city, street, country, or address, among others. Field 294 
indicates the size or resolution of the sign, and field 296 provides a list of fonts 

15 supported by the sign. Field 298 includes the network address of the sign through 
which the sign controller therefor can be accessed by the sign management system. 
Moreover, field 299 provides an identification of the color capabilities of the sign, 
e.g., the color depth or range of color supported by the sign. Additional information, 
e.g., whether the sign is capable of supporting video or animation, among other 

20 display capabilities may also be stored in sign record 288 consistent with the 
invention. 

Figure 12 illustrates a representative electronic order, or message request, 
record 300 consistent with the invention. Record 300 includes a user ID field 302 that 
identifies the user with which the record is associated. Field 304 provides a linked list 

25 of message records 250' that are configured in a similar manner to message record 
250 of Fig. 10, with the addition of a next record field in each message record 250' 
that points to the next record in the linked list. As shown in Fig. 12, multiple message 
records may be associated with a given message request, corresponding to the 
addition of a new page as described above in connection with message editor 170. 

30 With this configuration, multiple messages may be displayed in sequence to constitute 
a single message for the purposes of the message request. 
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Field 306 provides a sign name identifying the selected sign associated with 
the message request. Similarly, field 308 identifies a time slot, or selected time, at 
which to display the selected message on the selected sign. Starting, ending, and/or 
duration information may be used to define a time slot, and multiple time slots (even a 
5 definition of a repeating time slot) may be stored in field 308. 

Field 310 provides method of payment information through which a user may 
be billed and a monetary amount can be collected from the user. Field 312 indicates 
the type of proof that the user has requested in connection with the message request. 
Furthermore, field 314 provides a proof frame indicator that indicates which frame of 

10 a multi-frame message should be captured by an image capture device to confirm 
display of a particular message on an electronic sign. 

Figure 13A next illustrates convert message routine 216 described above in 
connection with Fig. 8. In particular, as discussed above, if a user modifies the sign 
type with which a particular message is associated, it may be necessary to modify the 

15 message to conform to the display capabilities of the new sign type. The message 

conversion process begins in block 320 by retrieving the new sign parameters, e.g., by 
accessing the database 58 for the sign parameters for the currently-selected sign type. 
Next, in block 322, the resolution is converted, including scaling as necessary the size 
of the message component and/or requesting the user to select a sub-region of the 

20 existing message (if going to a lower resolution) or where to locate a previous 
message (if going from a lower to a higher resolution). 

Next, in block 324, the color space of the message is converted, and in block 
326 the frame rate of any animation or video is converted. Next, in block 328 any 
non-supported effects are converted to other effects mapped to those non-existent 

25 effects. If desirable, a user may also be queried to select alternate effects if a 

particular effect is not supported by a new sign type. It should be appreciated that the 
conversion of resolution, color space, frame rate and effects are all well known image 
processing techniques. As such, a further discussion of such operations is not 
necessary for a full understanding of the invention. 

30 Once the display capabilities of the sign have been used to convert the 

message, the message record is updated in block 330 and the editor window is 
refreshed, if necessary, in block 332. Conversion of the message is then complete. 
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Fig. 13B illustrates create simulation routine 220 in greater detail. First, in 
block 732, the capabilities of the selected electronic sign are retrieved from the server 
computer. Next, in block 734, a simulated sign background image is created, based 
upon the sign capabilities of the selected sign. Typically, the simulated background 
5 includes the relative horizontal and vertical dimensions of the sign. In addition, for 
some signs, it may be desirable to incorporate simulated representations of the 
individual display elements (e.g., LED's or LCD's) of the physical sign. 

Next, in block 736, the first frame of the message is generated using the 
information in the message record. Next, in block 738, a window is opened on the 

10 user's computer display displaying the first frame superimposed over the background 
image of the selected sign. Next, in block 740, it is determined whether the message 
includes animations/videos or effects, any of which necessitate the generation of 
multiple frames for the simulated message. If not, routine 220 is complete. 

If, however, a message requires multiple frames, control passes to block 742 to 

15 insert a delay based upon the animation speed or effect speed specified in the message 
record. Next, block 744 generates the next frame for the message, or if the last frame 
was displayed, regenerates the first message frame. Next, block 746 updates the 
window to display the next frame. Control then returns to block 742 to continue 
animating the message. Display of the message occurs repeatedly until the window is 

20 closed by the user. In the alternative, the message may be displayed only once. Also, 
a user may be provided with a control to permit the message to be redisplayed as 
desired. Other alternatives will become apparent to one of ordinary skill in the art 
having benefit of the instant disclosure. 

Figure 14 illustrates at 340 the sequence of operations performed in 

25 scheduling a message in response to user selection of user interface control 90 of Fig. 
4. First, in block 342, the desired date and time interval during which to display a 
message is input by the user. Other or additional chronological information may also 
be input, e.g., the availability of a repeating time interval, a duration of a time . 
interval, etc. Next, in block 344, the scheduler module is accessed to determine if the 

30 requested time interval is available for the selected sign. It should also be appreciated 
that if no sign is currently selected, the user may be queried to select a sign prior to 
proceeding to block 344. Next, in block 346, the scheduler returns the result of the 
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query, and it is determined whether the requested time interval is available. If not, 
control passes to block 347 to indicate that the time interval is unavailable, and 
control returns to block 342 to have the user input alternate information. 

If the time interval is available, however, control passes to block 348 to 

5 indicate such to the user and display a list of the available time slots that match the 
time interval requested by the user. Next, in block 349, the desired date and time 
corresponding to at least one of the available time slots is obtained from the user. 
Next, in block 350, the cost (if any) of the message is displayed to the user. In 
particular, different signs may have different cost structures, which may also vary 

1 0 depending upon date, time, or other chronological information. For example, 

displaying an advertisement outside of a stadium just prior to a football game would 
demand a higher price than displaying the same message on the same sign at 4:00 
AM. Any number of pricing structures may be supported, as would be well known to 
those in the advertising art. 

15 Next, block 352 waits for confirmation from the user. Based upon the 

confirmation, it is determined whether the user wishes to proceed in block 354. If the 
user does not wish to proceed based upon the cost and/or availability, control passes 
to block 356 to query the user as to whether the user wishes to select another time 
slot. If so, control returns to block 342. If not, however, the message scheduling 

20 operation is completed without a time slot selected for the message. 

Returning to block 354, if the user responds with positive confirmation, 
control passes to block 358 to update the message record with the selected time slot. 
Next, in block 360, the scheduler is notified to reserve the requested time slot for a 
short period of time (e.g., one hour). This limited-duration reservation of a time slot 

25 in essence permits a user to lock-out other users from a particular time slot while that 
user completes the message request. Otherwise, a user might select a time slot, then 
proceed with creating a message and submitting an order, only to find that another 
user has since purchased that time slot in the interim. Of course, if the user with 
which a reservation has been made does not complete the message request in the 

30 allotted time, the scheduler is configured to release the reservation and permit other 
users to select that previously-reserved time slot. 
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Once the scheduler has been notified to reserve the time slot, the message 
scheduling operation is complete. Control then typically returns to display the 
message request home page 84 to permit the user to proceed with the ordering 
process. 

5 Figures 15A and 15B respectively illustrate representative HTML documents 

370, 380 that may be displayed in browser window 82 during interactive scheduling 
of a message during the sequence of operations in Fig. 14. Document 370 of Fig. 15A 
is typically displayed to receive the user input of a time interval, corresponding to 
block 342 of Fig. 14. To this extent, document 370 includes a series of date input 

10 fields 372 through which a user enters a starting and ending day, month and/or year. 
Hour and minute ranges are respectively input through input fields 374 and 376. A 
"get free slots" button control 378 is used to submit the information to the sign 
management system, and a reset button control 379 is used to clear the information 
currently displayed in the input fields. 

15 Document 380 of Fig. 15B is typically displayed to receive the user input of a 

time slot among the available time slots, corresponding to blocks 348 and 349 of Fig. 
14. To this extent, document 380 includes a list box control 382 displaying the 
available time slots. In addition, document 380 includes input fields 384, 386 and 388 
to input the date, hour and minute of a desired time slot (which may represent only a 

20 portion of an available time slot). Button control 390 is used to submit the input to 
the sign management system, and button control 392 is used to clear the information 
currently displayed in the input fields. 

It will be appreciated that other user input mechanisms may be used to input 
both time intervals and specific time slots. For example, an entire time slot could be 

25 selected simply through selecting an entry in list box 382, among other operations. 

Figure 16 illustrates at 400 the sequence of operations performed in selecting a 
proof mode in response to user selection of user interface control 92 of Fig. 4. First, 
at block 402, the user supplies an auto/demand selection to the system, indicating 
whether the user wishes to receive automatic confirmation of the display of the 

30 requested message, or whether the user wishes to receive confirmation "on demand" 
or manually. Automatic confirmation is typically provided through the use of an e- 
mail sent to an e-mail address specified by the user when the message has been 



WO 00/63771 



PCT/USOO/10260 



-30- 

displayed and the request has been fulfilled. The "on demand" confirmation is 
implemented using a file transfer protocol (FTP) server that is accessible to a user to 
permit the user to download the confirmation anytime after the confirmation has been 
placed on the server after fulfillment of the message request. With this latter form of 
5 confirmation, typically a user is required to input a user name and password to an FTP 
server to permit the confirmation to be downloaded to the user's computer. As such, 
it may be necessary to have the user supply the sign management system with a 
password that the user will be able to input to have access to the FTP server. 

Once the auto/demand selection has been made by the user, a proof frame is 

10 next retrieved from the user in block 404 for message requests that specify animation 
or multiple frames. Specifically, as discussed above, it is often desirable to provide as 
confirmation an image of the electronic sign displaying the message requested by the 
user. This provides the user with positive verification that the request was fulfilled. 
An enhancement of this feature is to permit a user to specify a specific frame in a 

15 multi-frame message to capture for confirmation of delivery. As such, in block 404 
the proof frame is retrieved from the user. 

Next, in block 406, the data input by the user is stored in the order record 
associated with the message request. Selection of the proof mode is then complete, 
and the user is returned to home page 84. 

20 Figure 17 illustrates a representative proof mode selection page 410 displayed 

in browser window 82. Page 410 includes a pair of linked radio buttons, 412, 414 
through which a user selects either the automatic or manual, or on-demand proof 
mode. For the automatic proof mode, an input box 416 is provided for a user to 
submit his or her e-mail address to which the confirmation will be sent. In the 

25 alternative, the user may input the e-mail address with his or her profile information at 
another stage of the message request generation process, whereby separate inputting 
of an e-mail address may not be required at this point. 

Moreover, as discussed above, for multi-frame messages, it may be desirable 
to specify a specific frame to capture, which is received through a user interface 

30 control 418. Confirmation of the input information is made through user selection of 
a button control 420, and a user is permitted to back out of page 410 without inputting 
proof information through selection of cancel button control 422. 
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Figure 18 illustrates at 430 the sequence of operations performed during the 
selection of the payment method in response to user selection of control 94 of Fig. 4. 
First, as shown in block 432, a ZIP code (if within the United States) or a country is 
obtained from the user. Next, the address of the user is obtained in block 434. Next, 
5 in block 436, a user is asked to select a payment method, in this implementation, 
either payment by credit card or by purchase order. If the user selects payment by 
credit card, control passes to block 438 to obtain credit card information from the 
user. If on the other hand, the user selects payment by purchase order, control passes 
instead to block 439 to get bank account information from the user. Once such 

10 information is input, the user is returned to home page 84 of Fig, 4. 

A series of suitable HTML documents 440, 450 and 462 for use in inputting 
method of payment information are respectively shown in greater detail in Figs. 19A- 
19C. Document 440 of Fig. 19A is displayed during selection of a payment method, 
corresponding to block 436 of Fig. 18. The method of payment may be selected, for 

15 example, through a drop-down list box control 442, with confirmation of the selection 
made via a continue button control 444. In addition, informational text 446 may also 
be provided to provide instructions to the user. 

Document 450 of Fig. 19B is displayed once a user has indicated that a credit 
card will be used as the selected payment method, corresponding to block 438 of Fig. 

20 18. The type of credit card may be selected, for example, through a drop-down list 
box control 452, with card number and expiration date entered through input fields 
454, 456. Completion of the order may be indicated via place order button control 
458, with informational text 460 used to provide additional instructions to the user. In 
the alternative, the control button 458 may be used to return to home page 84 to 

25 permit the user to separately submit the order via control button 96. 

Document 460 of Fig. 19C is displayed once a user has indicated that a 
purchase order will be used as the selected payment method, corresponding to block 
439 of Fig. 18. The user's bank account number and purchase order number may be 
entered through input fields 464, 466, and completion of the order may be indicated 

30 via place order button control 468. Additional informational text 469 may also be 
included to provide instructions to the user. 
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Figure 20 illustrates at 480 the sequence of operations performed in response 
to user selection of submit order button 96 of Fig. 4 (in the alternative, the sequence 
of operations can be performed responsive to selection of a "place order" button 
control, e.g., as shown in Figs. 19B and 19C. 
5 The sequence of operations shown at 480 are performed by main control 

module 48. First, in block 482, order verification module 60 (Fig. 3) is called to 
determine whether the submitted order is suitable for processing. Then, if module 60 
confirms that the order is suitable for processing, monitoring and approval module 62 
(Fig. 3) is called in block 484 to determine whether the content of the message 

10 specified in the order is appropriate. If so, control then passes to block 486 to submit 
the message to the scheduler module 64 (Fig. 3). If the scheduling operation 
succeeds, control passes to block 488 to debit the bank/credit card account (as 
appropriate), in a manner well known in the art. Next, block 490 determines whether 
the debit was successful. If so, control passes to block 491 to notify proof of display 

15 module 68 to provide a proof of display image at the time, and optionally frame, 

specified in the submitted order. Next, in block 492, a confirmation email is sent to 
the email account specified in the order to confirm that the message has been 
scheduled for display. In the email, additional information, such as a summary of the 
order parameters and a receipt for the charge to the user's account, may also be 

20 provided. 

Next, as shown at block 494, the main control module waits until the message 
is displayed, whereby, as shown at block 496, a proof of display email is sent to the 
user, if that option was selected by the user during creation of the order. If not, no 
such email is sent. It should be appreciated that waiting for the message to be 

25 displayed need not positively executed by main control module 48, rather, the main 
control module may terminate handling of the order at block 492, and then execute 
block 496 asynchronously after notification from another module in the sign 
management system (e.g., either of modules 64, 68). Also, as illustrated in blocks 
482, 484, 486 and 490, if any of modules 60, 62 or 64 return a negative result, or if 

30 the debit operation is unsuccessful, control instead passes to block 498 to cancel the 
order and notify the user of the cancellation thereof. 
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The operation of order verification module 60 is illustrated by order 
verification routine 500 in Fig. 21. First, in block 502, the availability of the selected 
time slot for the order is verified by accessing scheduler module 64 (Fig. 3). If the 
selected time slot is still available, the message parameters are compared with the 
5 capabilities of the selected sign in block 504 to determine whether the message 

parameters are compatible (including accessing the sign capabilities stored in database 
58 (Fig. 3). 

If the message is compatible, control passes to block 506 to verify that the 
message context is appropriate — that is, whether the content of the message is 

10 compatible with the message display service provider. As but one' example, a 

message advertising a particular product should not be displayed on an electronic sign 
owned by a competitor. Also, a message espousing a particular political view may 
not be acceptable to a particular message display service provider. Thus, it may be 
desirable to permit a sign's capabilities to include a list of terms that are inappropriate 

15 for display on the sign. As a result, block 506 may be implemented by performing a 
search to locate any inappropriate terms. 

Assuming the message context is appropriate, control next passes to block 508 
to verify whether the user's address is legal, e.g., by checking that all address 
components are provided, that the ZIP code exists, that the city and state match that 

20 assigned to the ZIP code, and/or that the street address exists and is located in the ZIP 
code, among others. If so, control then passes to block 510 to determine whether the 
credit carcL^bank account supplied by the user is valid (e..g, by accessing the 
appropriate credit agency or bank, in a manner known in the art). If so, the order is 
verified, as represented at block 512, and a "valid" response is returned from module 

25 60). However, if any of blocks 502-5 10 return a "fail" result, this result is output 
from module 60, as represented at block 514. 

The operation of monitoring and approval module 62 is illustrated by 
monitoring & approval routine 520 in Fig. 22. First, in block 522, the configuration 
of the sign is retrieved from database 58. Next, in block 524, it is determined whether 

30 the message is configured for monitoring and approval, which depends upon factors 
such as the specific electronic sign, where the electronic sign is located, what 
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audience is expected to view the electronic sign, and who is expected to post 
messages to the electronic sign. 

Assuming first that the message is configured for monitoring and approval, 
control passes to block 526 to determine whether the message includes text. If so, 
5 control passes to block 528 to perform automatic searching for forbidden 

words/characters, e.g., using any conventional parental/content filtering algorithms 
known in the art. In addition, at block 529, it is determined whether an additional, 
manual review of the text in the message is required. If so, control passes to block 
532 to notify an administrator to obtain manual review and approval of the message 

10 content. Control then passes to block 534 to determine whether the message content 
is approved. Otherwise, if no manual review of the text is required, block 529 passes 
control to block 530 to determine whether the message includes graphics. Moreover, 
returning to block 526, if no text is included in the message, control also passes to 
block 530 to continue processing of the message. 

15 If the message does include graphics, control also passes to block 532 to notify 

an administrator to obtain manual review and approval of the message content. Then, 
after receiving manual review, or if no graphics are included in the message, control 
passes to block 534 to determine whether the message content is approved. If so, a 
"pass" result is returned, as represented by block 536. If not, a "fail" result is 

20 returned, as represented by block 538. Also, returning to block 524, if the message is 
not configured for monitoring and approval, control passes directly to block 536. In 
the alternative, content monitoring may be omitted, or may always be performed 
regardless of the electronic sign. It should also be appreciated that any other 
combination of automated and/or manual review may be utilized in other 

25 embodiments consistent with the invention. 

The operation of scheduler module 64 is illustrated by scheduler routine 570 in 
Fig. 23. Scheduler routine 570 is illustrated as an event-driven routine, waiting for 
events in block 572, and detecting received events at blocks 574-580. Moreover, as 
shown in block 582, the scheduler routine periodically checks a message queue and 

30 submits any pending message to the appropriate sign controller for the electronic sign 
selected for that message. Moreover, as is known in the art, each sign controller 
typically includes scheduling capabilities such that submission of a message to the 
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sign controller, as well as a specific time slot to display that message (using the 
controller-specific control signals provided by the sign control driver 66 for that sign), 
is sufficient to ensure that the message will be displayed at the appropriate time. In 
the alternative, scheduling capabilities may be incorporated directly into scheduler 
5 module 64, rather than relying on the capabilities provided by conventional sign 
controllers. 

One type of event handled by scheduler routine 570 is a request to determine 
the availability of a particular sign over a particular time interval. Such an event is 
detected in block 574 and handled in block 590 by determining whether the specified 

10 sign is available at the time specified in the event. Such information is returned to the 
main control module, also including the specific time slots that are available within 
the specified time interval. The information is determined by accessing a message 
queue maintained within the scheduler module 64. In the alternative, the information 
can be determined by accessing a local message queue maintained in the appropriate 

15 sign controller. 

Another type of event handled by scheduler routine 570 is a reserve time slot 
event, which is detected in block 576 and handled in block 592 by blocking out the 
specified time slot for the specified user, typically to give the user time to complete 
the creation of an order. In addition, a reservation timer (e.g., one hour) is set. By 

20 doing so, the time slot is made temporarily unavailable to other users until the timer 
expires. Expiration of a timer is detected in block 578 and handled in block 594 by 
clearing the previously-set block, thereby freeing the reserved time slot for selection 
by other users. Another type of event handled by scheduler routine 570 is a message 
submitted event, which is detected in block 580 and handled in block 596 by adding 

25 the message to the message queue maintained in the scheduler module. Doing so also 
clears the reservation timer, with the block being replaced by the new message. 

The operation of proof of display module 68 is shown at 620 in Fig. 24. 
Module 68 may be located within a server computer (as shown in Fig. 3), or in the 
alternative, located within a sign controller and/or remote electronic device coupled to 

30 an image capture device. First, as shown at block 622, a snapshot of the electronic 
sign is captured on a periodic basis (e.g., n times a second), in a manner known in the 
art. Next, as shown at block 624, the last captured snapshot is forwarded to the main 
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control module in response to a request made by such module. Next, it is determined 
in block 626 whether a previously-stored proof of display time was reached — that is, 
whether a proof of delivery time specified in a particular message request has been 
reached. If so, control passes to block 628 to store the snapshot in a file transfer 
5 protocol (FTP) account accessible by the user that created the message to provide 
proof of delivery therefor. In addition, block 628 may also notify the main control 
module that the snapshot has been stored, so that the main control module may 
forward a proof of delivery email to the user if the user had requested such. 

Upon completion of block 628, or if no proof of display time has been 

10 reached, control passes to block 630 to determine whether a new proof of display 

time has been forwarded from the main control module (e.g., at block 491 of Fig. 20). 
If not, control returns to block 622. If so, however, the proof of display time is stored 
for watching by module 68. Control then returns to block 622. 

As discussed above, it may be desirable in certain implementations to 

1 5 distribute sign management functions among a plurality of server computers coupled 
to one another via a private and/or public communications link. As shown in Fig. 25, 
for example, a sign management system 700 is shown including a global sign 
management system gateway 702 coupled to a plurality of sign managers 704 over the 
Internet 34. It is anticipated that a user may log on and authenticate to any sign 

20 manager 704 in the manner discussed above. In the alternative, the user may register 
with the global sign management system gateway 702 to select among a plurality of 
available signs distributed among the various sign managers. Through this 
architecture, a user is able to select among a larger of available signs, and have the 
distribution of a message request transmitted to the appropriate sign manager for 

25 handling. Moreover, the complete ordering process may be handled by gateway 702, 
with the completed order sent to the various sign managers 704 as appropriate. In the 
alternative, only a portion of the message request ordering process may be handled by 
gateway 702, with the user transferred to the appropriate sign manager to complete 
the order. 

30 For example, as shown at Fig. 26, the sequence of operations in directing a 

message request to a particular sign manager are illustrated at 710. First, after a user 
accesses the gateway 702, the user is permitted to select globally among a plurality of 
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available signs available through the sign management system, as shown at block 712. 
As a component of this operation, it may be necessary for the gateway to transmit 
availability requests to the various sign managers and retrieve availability information 
from each sign manager. Moreover, a preview function may also require the 
5 interaction between the gateway and the respective sign managers. 

Next, as shown in block 714, the user is directed to the home page of the 
selected sign manager. Moreover, it may be desirable to notify that sign manager of 
the sign that was selected by the user. In the alternative, the sign manager may not be 
informed of the specific sign requested by the user, whereby the user would be 

10 required to select that sign again as discussed above in connection with Fig. 5. In this 
latter implementation, the gateway may be as simple as a sequence of HTML 
documents through which a user can search for different signs at different locations, 
with the selection of any of those signs and/or locations used to simply direct the user 
to the particular sign manager for an operation principally in the manner discussed 

15 above for sign management system 10. In the alternative, however, a greater deal of 
interactivity may be provided between gateway 702 and each sign manager 704 to 
facilitate the streamlined processing of message requests throughout system 700. 

As shown at block 716, once the user is routed to the home page of the 
selected sign manager, that sign manager then permits the user to log in in the manner 

20 described above. Then, as shown at block 718, the order process is continued, e.g., by 
displaying message request home page 84 of Fig. 4 and permitting order selection 
through the process described above. 

Alternate manners of distributing the functionality of a global sign 
management system between a gateway and individual sign managers may be used in 

25 the alternative. Therefore, the invention should not be limited to the particular 
distribution or allocation of functionality as described herein. 

It should be appreciated that additional functions may be supported by a sign 
management system consistent with the invention. For example, a user may be able 
to obtain general background information about the sign management system and its 

30 operation. Moreover, a sign management system may permit message display service 
providers to obtain information about how to purchase the system and/or how to 
contract for the services of an existing sign management system. An interactive 
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manner of ordering service and/or sign management system may also be provided. 
Also, a user may be able to retrieve descriptive information about a particular sign 
during the selection process thereof. Further, a user may be permitted to have an 
account in the sign management system and to retrieve previously-prepared messages 
5 on a recurring basis. Also, a message display service provider may also be able to 
obtain statistical information regarding the orders placed to his or her owned 
electronic sign. 

Moreover, a user may have access (after authorization) to an FTP account to 
retrieve proof of display images. Furthermore, a user may be permitted to purchase 

10 proof of display images, e.g., as a memento of the purchase of the message. A value 
added service, for example, may include mailing a framed copy of a proof of display 
image to a message recipient (e.g., a person whose birthday was announced in a 
message). Other uses for proof of display images will be envisioned by one of 
ordinary skill in the art having benefit of the instant disclosure. 

15 As an additional alternative, it may be desirable to support audio capabilities 

in connection with the display of a message on an electronic sign, e.g., including a 
voice message, background music, sound effects, etc. Audio may be a component of 
a video clip, or may be a separate multimedia object associated with the message. 
Handling of audio may be handled in any number of manners, e.g., similar to the 

20 manner described herein for editing, selecting, and processing image, animation, and 
video multimedia components of a message. 

Other modifications will be apparent to one of ordinary skill in the art. 
Therefore, the invention lies in the claims hereinafter appended. 
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What js claimed js: 

1 1. A method of controlling an electronic sign, the method comprising: 

2 (a) accepting electronic message requests from a plurality of 

3 independent users over an electronic communications link, each electronic 

4 message request associated with a selected message and a selected time to 

5 display the selected message; and 

6 (b) processing received electronic message requests to generate 

7 control signals for use in electronically controlling an electronic sign. 

1 2. The method of claim 1, wherein the electronic sign is selected from the 

2 group consisting of a light emitting diode (LED) sign, a liquid crystal display (LCD) 

3 sign, a plasma display sign, a cathode ray tube (CRT) sign, a bulb sign, and a flip dot 

4 sign. 

1 3. The method of claim 1, further comprising transmitting the control signals 

2 to the electronic sign over a communications medium selected from the group 

3 consisting of a direct cable, a radio frequency (RF) transmission, a telephone line, an 

4 infrared (IR) transmission, and a computer network cable. 

1 4. The method of claim 1, further comprising, responsive to receipt of an 

2 electronic message request, debiting a user account using payment information 

3 associated with the electronic message request. 

1 5. The method of claim 1, wherein accepting electronic message requests 

2 from the plurality of users includes accepting data for the electronic message requests 

3 over a public communications network. 

1 6. The method of claim 1, further comprising transmitting the control signals 

2 to the electronic sign over a public communications network. 

1 7. The method of claim 1, wherein each electronic message request is further 

2 associated with a selected electronic sign among a plurality of electronic signs, the 
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3 method further comprising, responsive to a first electronic message request, 

4 transmitting a control signal to a first electronic sign from the plurality of electronic 

5 signs associated with the first electronic message request. 

1 8. The method of claim 7, wherein accepting electronic message requests 

2 from a plurality of users includes interacting with a first user through an on-line 

3 interactive interface. 

1 9. The method of claim 8, wherein interacting with the first user includes: 

2 (a) receiving a sign search criteria from the first user; 

3 (b) determining a subset of matching electronic signs from the 

4 plurality of electronic signs that match the sign search criteria; and 

5 (c) associating at least one electronic sign from the subset of matching 

6 electronic signs with the first electronic message request. 

1 10. The method of claim 9, wherein interacting with the first user further 

2 includes identifying the electronic signs in the subset of matching electronic signs to 

3 the first user, wherein associating the electronic sign with the first electronic message 

4 request is performed responsive to user selection of at least one electronic sign from 

5 the subset of matching electronic signs. 

1 11. The method of claim 9, wherein receiving the sign search criteria includes 

2 receiving at least one of a location criteria, a time criteria, and a display capability 

3 criteria from the first user. 

1 12. The method of claim 8, wherein interacting with the first user further 

2 includes: 

3 (a) transmitting availability information for at least one electronic sign 

4 to a user, the availability information identifying a plurality of available time 

5 slots for the electronic sign; 

6 (b) receiving a user selection of a selected time slot from the plurality 

7 of available time slots; and 
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8 (c) associating the selected time slot with the first electronic message 

9 request. 

1 13. The method of claim 8, wherein interacting with the first user further 

2 includes receiving user input defining a first message. 

1 14. The method of claim 13, wherein interacting with the first user further 

2 includes generating a computer simulation of a display of the first message on the first 

3 electronic sign. 

1 15. The method of claim 13, wherein interacting with the first user further 

2 includes constraining user input defining the first message based upon a display 

3 capability of the first electronic sign. 

1 16. The method of claim 15, wherein interacting with the first user further 

2 includes: 

3 (a) receiving user input to associate a second electronic sign with the 

4 first electronic message request instead of the first electronic sign; and 

5 (b) responsive thereto, converting at least on display characteristic of 

6 the first message based upon a display capability of the second electronic sign. 

1 17. The method of claim 13, wherein interacting with the first user further 

2 includes: 

3 (a) transmitting available content information to a user, the available 

4 content information identifying a plurality of available message components 

5 available for display on an electronic sign; 

6 (b) receiving a user selection of a selected message component from 

7 the plurality of available message components; and 

8 (c) associating the selected message component with the first 

9 electronic message request. 
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1 18. The method of claim 13, wherein interacting with the first user further 

2 includes: 

3 (a) transmitting available effect information to a user, the available 

4 effect information identifying a plurality of available message effects available 

5 for use in displaying a message on an electronic sign; 

6 (b) receiving a user selection of a selected message effect from the 

7 plurality of available message effects; and 

8 (c) associating the selected message effect with the first electronic 

9 message request. 

1 19. The method of claim 13, wherein receiving user input defining the first 

2 message includes receiving message information selected from the group consisting 

3 of text information, image information, message effect information, animation 

4 information, video information, and combinations thereof 

1 20. The method of claim 8, wherein interacting with the first user includes 

2 selecting an electronic sign among the plurality of electronic signs with which to 

3 associate with the first electronic message request, including: 

4 (a) in response to first user input, capturing and transmitting to the 

5 first user a current image of a first electronic sign among the plurality of 

6 electronic signs; 

7 (b) in response to second user input, associating the first electronic 

8 sign with the first electronic message request. 

1 21. The method of claim 8, wherein interacting with the first user includes 

2 transmitting at least one platform independent document to the first user. 

1 22. The method of claim 21, wherein the platform independent document is 

2 formatted in hypertext markup language (HTML). 

1 23. The method of claim 8, wherein interacting with the first user includes: 

2 (a) determining a platform associated with the first user, and 
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3 (b) transmitting a platform specific program to the first user based 

4 upon the platform associated therewith. 

1 24. The method of claim 1, further comprising verifying a first electronic 

2 message request prior to generating a control signal for use in electronically 

3 controlling the electronic sign responsive to the electronic message request. 

1 25. The method of claim 24, wherein verifying the first electronic message 

2 request includes at least one of verifying availability of a first time associated with the 

3 first electronic message request, verifying compatibility of a first message associated 

4 with the first electronic message request with a display capability of the electronic 

5 sign, verifying a payment associated with the first electronic message request, and 

6 verifying content-appropriateness of the first message. 

1 26. The method of claim 1, further comprising verifying content- 

2 appropriateness of a message request prior to generating a control signal for use in 

3 electronically controlling the electronic sign responsive to the message request. 

1 27. The method of claim 1 , further comprising confirming acceptance of a 

2 first electronic message request from a first user. 

1 28. The method of claim 27, wherein confirming acceptance of the first 

2 electronic message request includes transmitting an electronic message to the first 

3 user. 

1 29. The method of claim 1, further comprising: 

2 (a) displaying on the electronic sign a first message associated with a 

3 first electronic message request from a first user; and 

4 (b) capturing an image of the electronic sign during display of the first 

5 message with an image capture device. 
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1 30. The method of claim 29, wherein the image capture device includes a 

2 digital camera positioned at a location suitable for viewing the electronic sign. 

1 31 . The method of claim 29, further comprising confirming display of the first 

2 message on the electronic sign by forwarding the image to the first user. 

1 32. The method of claim 31, wherein forwarding the image to the first user 

2 includes transmitting the image in an electronic message to the first user. 

1 33. The method of claim 31, wherein forwarding the image to the first user 

2 includes: 

3 (a) obtaining authorization information from the first user, and 

4 (b) thereafter transmitting the image to the first user. 



1 
2 
3 



34. The method of claim 29, wherein the first message includes a plurality of 
frames, and wherein capturing the image of the electronic sign includes capturing the 
image during display of a selected frame among the plurality of frames. 
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1 35. A method of controlling an electronic sign, the method comprising: 

2 (a) receiving a plurality of electronic message requests from a plurality 

3 of independent sources over a public communications network, each electronic 

4 message request associated with a selected message; 

5 (b) scheduling the plurality of electronic message requests; and 

6 (c) generating control signals for use in electronically controlling an 

7 electronic sign to display the selected messages associated with the plurality of 

8 electronic message requests. 
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1 36. A method of vending advertising space on an electronic sign, the method 

2 comprising: 

3 (a) interacting with a plurality of users through an on-line computer 

4 interface to generate a plurality of electronic orders, with each electronic order 

5 specifying a selected message, a selected time at which to display the selected 

6 message, and payment information identifying a selected manner of payment 

7 for the display of the selected message on the electronic sign; 

8 (b) processing each electronic order to schedule display of the selected 

9 message associated therewith on the electronic sign; 

10 (c) processing each electronic order to handle payment for display of 

11 the selected message associated therewith; and 

12 (d) transmitting control signals to the electronic sign so as to control 

13 the electronic sign to display the selected message associated with each 

14 electronic order at the selected time therefor. 
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1 37. An apparatus, comprising: 

2 (a) an on-line user interface configured to accept electronic message 

3 requests from a plurality of users over an electronic communications link, each 

4 electronic message request associated with a selected message and a selected 

5 time to display the selected message; and 

6 (b) a sign manager, operably coupled to the on-line user interface to 

7 electronically receive electronic message requests therefrom, the sign manager 

8 configured to process received message requests and generate therefrom at 

9 least one control signal for use in electronically controlling an electronic sign. 

1 38. The apparatus of claim 37, wherein the electronic sign is selected from the 

2 group consisting of a light emitting diode (LED) sign, a liquid crystal display (LCD) 

3 sign, a plasma display sign, a cathode ray tube (CRT) sign, a bulb sign and a flip dot 

4 sign. 

1 39. The apparatus of claim 37, wherein the sign manager is operably coupled 

2 to the electronic sign via a communications medium selected from the group 

3 consisting of a direct cable, a radio frequency (RF) transmission, a telephone line, an 

4 infrared (IR) transmission, and a computer network cable. 

1 40. The apparatus of claim 37, wherein the sign manager is further configured 

2 to debit a user account using payment information associated with an electronic 

3 message request. 

1 41 . The apparatus of claim 37, wherein the on-line user interface is configured 

2 to accept electronic message requests from at least one of the plurality of users over a 

3 public communications network. 

1 42. The apparatus of claim 37, wherein the sign manager is coupled to the 

2 electronic sign over a public communications network. 
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1 43. The apparatus of claim 37, wherein the sign manager is coupled to a 

2 plurality of electronic signs, and wherein the on-line user interface is configured to 

3 receive a selected electronic sign among the plurality of electronic signs with which to 

4 associate an electronic message request. 

1 44. The apparatus of claim 43, wherein the on-line user interface is configured 

2 to provide the first user with a subset of matching electronic signs matching a sign 

3 search criteria input by the first user. 

1 45. The apparatus of claim 44, wherein the sign search criteria includes at 

2 least one of a location criteria, a time criteria, and a display capability criteria. 

1 46. The apparatus of claim 43, wherein the on-line user interface is further 

2 configured to display to the first user a current image of a first electronic sign among 

3 a plurality of electronic signs during user selection of an electronic sign with which to 

4 associate an electronic message request. 

1 47. The apparatus of claim 37, wherein the on-line user interface is configured 

2 to provide the first user with availability information that identifies a plurality of 

3 available time slots for the electronic sign. 

1 48. The apparatus of claim 37, wherein the on-line user interface is further 

2 configured to generate a computer simulation of a display of the first message on the 

3 electronic sign. 

1 49. The apparatus of claim 37, wherein the on-line user interface is further 

2 configured to receive user input defining the first message selected from the group 

3 consisting of text information, image information, message effect information, 

4 animation information, video information, and combinations thereof. 
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1 50. The apparatus of claim 37, wherein the on-line user interface is configured 

2 to interact with the first user by transmitting at least one HTML document to the first 

3 user. 

1 51. The apparatus of claim 37, wherein the sign manager is further configured 

2 to verify a first electronic message request prior to generating a control signal for use 

3 in electronically controlling the electronic sign responsive to the first electronic 

4 message request, by performing at least one of verifying availability of a first time 

5 associated with the first electronic message request, verifying compatibility of a first 

6 message associated with the first electronic message request with a display capability 

7 of the electronic sign, verifying a payment associated with the first electronic message 

8 request, and verifying content-appropriateness of the first message. 

1 52. The apparatus of claim 37, wherein the sign manager is further configured 

2 to verify content-appropriateness of a message request prior to generating a control 

3 signal for use in electronically controlling the electronic sign responsive to the 

4 message request. 

1 53. The apparatus of claim 37, wherein the sign manager is further configured 

2 to confirm acceptance of a first electronic message request by transmitting an 

3 electronic message to the first user. 

1 54. The apparatus of claim 37, further comprising an image capture device 

2 positioned at a location suitable for viewing the electronic sign, and wherein the sign 

3 manager is further configured to store an image of the electronic sign during display 

4 of a first message associated with a first electronic message request from a first user. 

1 55. The apparatus of claim 54, wherein the sign manager is further configured 

2 to forward the image to the first user to confirm display of the first message on the 

3 electronic sign. 
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56. The apparatus of claim 55, wherein the sign manager is further configured 
to transmit the image in an electronic message to the first user. 

57. The apparatus of claim 54, wherein the first message includes a plurality 
of frames, and wherein the sign manager is further configured to store an image taken 
during display of a selected frame among the plurality of frames. 
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1 58. A program product, comprising: 

2 (a) a program including an on-line user interface configured to accept 

3 electronic message requests from a plurality of users over an electronic 

4 communications link, each electronic message request associated with a 

5 selected message and a selected time to display the selected message; and a 

6 sign manager, operably coupled to the on-line user interface to electronically 

7 receive electronic message requests therefrom, the sign manager configured to 

8 process received message requests and generate therefrom at least one control 

9 signal for use in electronically controlling an electronic sign; and 
10 (b) a signal bearing media bearing the program. 

1 59. The program product of claim 58, wherein the signal bearing media 

2 includes at least one of a transmission type media and a recordable media. 
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1 60. An apparatus, comprising: 

2 (a) an image capture device positioned at a location suitable for 

3 viewing an electronic sign; and 

4 (b) a sign manager operably coupled to electronically control both the 

5 image capture device and the electronic sign. 



WO 00/63771 



PCT/USOO/10260 



-53- 

61 . A method of confirming display of a message on an electronic sign, the 
method comprising: 

(a) capturing an image of the electronic sign during display of the 
message using an image capture device positioned at a location suitable for 
viewing the electronic sign; and 

(b) transmitting the image to a location remote from the electronic 

sign. 
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62. A method of generating a message for display on an electronic sign, the 
method comprising: 

(a) transmitting a current image of at least one of a plurality of 
electronic signs to a user; and 

(b) receiving a user selection of at least one of the plurality of 
electronic signs. 
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63. A method of generating a message for display on an electronic sign, the 
method comprising: 

(a) constructing a message in response to input from a user; and 

(b) generating a computer simulation of a display of the message on 
the electronic sign; and 

(c) displaying the computer simulation to the user that is constructing 
the message. 
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